Closed Bug 326732 Opened 19 years ago Closed 18 years ago

disabled submit inputs have text selection (I-beam) cursor

Categories

(Core :: Layout: Form Controls, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: aguertin+bugzilla, Unassigned)

References

()

Details

(Keywords: regression, testcase)

Disabled submit inputs have the text cursor instead of an arrow like non-disabled ones. Testcase in URL. 

Does not occur on FF1.5 Windows, so I'm assuming it's a regression, though it could conceivably be Linux only...
No, I can see it too on windows, with current trunk build.
Might be useful to know when this regressed.
Regression between 1.9a1_2006012517 and 1.9a1_2006012609.
Ah, thanks Ria. So I guess bug 317375 is responsible for the change in behavior.
But it seems to me this behavior is a logical consequence, considering the cursor: inherit; rules in forms.css for disabled inputs.
This was added with bug 260399. Boris you insisted on changing it from "default" in the CSS to "inherit". Are you sure it shouldn't be "default"?
Blocks: 317375
> But it seems to me this behavior is a logical consequence, considering the
> cursor: inherit; rules in forms.css for disabled inputs.

Why?  It seems to me the behavior is a logical consequence of roc changing (well, actually removing) the hit-testing going on in nsHTMLButtonControlFrame in bug 317375.

> Are you sure it shouldn't be "default"?

Yes, since "cursor" is inherited.  Consider:

  <div style="cursor: pointer"><input disabled></div>

Imo the cursor should be a pointer (which is what it would be if input were not special), not an arrow (which is what it would be if we use "default").

In any case, the inherit is not the problem.  The problem that the text frame is ending up as the target when we're doing UpdateCursor is.  That didn't use to be the case.

That said, the old hit testing in nsHTMLButtonControlFrame is a little odd for <button>.  Perhaps nsGfxButtonControlFrame should override some of this stuff?  After all, an <a> inside a <button> should be clickable, and I'm not sure it was before...
Flags: blocking1.9a1?
Yeah, you're right.

I guess this bug and bug 326827 could be related to each other.
Yeah, indeed.  The same code's involved.
Depends on: 326827
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.